Knowledge Accumulator

RQ-VAE: практический гайд по выживанию

Несколько месяцев назад я делал обзор на статью по рекомендациям, базирующейся на так называемых Semantic IDs.

Напомню базовый смысл - мы хотим научиться сжимать большие эмбеддинги документов в список id-шников из небольшого словаря, которые позволяют сохранить большую часть информации о контенте документа. Расскажу про грабли, которые собрал, пока экспериментировал с этим у себя.

Первое и важнейшее - так как я человек ленивый, собирать отдельный пайплайн для обучения полноценного автоэнкодера я не захотел - с нашими миллиардами твитов в секунду любая операция над данными это больно. Созрел хитрый план.

Так как я уже работал над двухбашенной моделью, одна из которых относится к документу, вместо того, чтобы обучать codebook на восстановление документных эмбеддингов, я решил попробовать захерачить RQ-боттлнек прямо внутрь документной башни. То есть выход документного энкодера, прежде чем пойти дружить с юзерным вектором, проходил через эту квантизацию, а дальше шёл уже восстановленный вектор.

Можно спорить о том, насколько такая постановка портит итоговые id-шники. Мы пытаемся записать в них не полноценное представление, а только то, что помогает предсказывать рекомендательный таргет. Но у подхода есть мощный плюс - интерпретируемая процедура эвала качества сжатия.

Я строил 3 графика обучения двухбашенной модели. Два бейзлайна - нижний и верхний - без контентных фичей документа и обычный бейзлайн, и третий - это модель с RQ-боттлнеком. Если ошибка третьей модели ровно посередине между 2 бейзлайнами, то это значит, что мы как бы теряем 50% качества при использовании квантизации, т.е. не нужно никаких дополнительных анализов для неутешительного вывода. Моей задачей было максимально приблизиться к верхнему бейзлайну.

Как любой уважающий себя программист, начал я с воровства кода с гитхаба, нашёл вот такую репу на пару сотен звёзд и вытащил оттуда только код самого боттлнека. Напомню, главная сложность обучения дискретного боттлнека - он недифференцируем. В коде было 3 варианта решения этой проблемы - использование Straight Through Estimator. как в изначальной статье, господин Гумбель и ещё какой-то третий.

Первый и третий давали процентов 70% от изначального качества, а вот Гумбель давал процентов 30. Интуиция говорила, что Гумбель не может быть хуже, чем Straight Through Estimator. Так как же так? Ответ убил.

В коде с гитхаба после подсчёта матрицы расстояний между векторами и кодами зачем-то вызывался detach. Гумбель софтмакс - дефолтная опция этого, казалось бы, популярного репозитория, оказалась почти полностью сломана. После его исправления модель стала давать примерно 80% от качества бейзлайна. В репе эту ошибку исправили примерно в тот же самый момент, несколько месяцев до этого висела сломанная версия. Не доверяйте людям с гитхаба...

Переход от 80% к 90% произошёл благодаря опции sim_vq - трюка из этой статьи. Идея в том, что мы представляем матрицу кодов не как матрицу параметров, а как произведение 2 матриц параметров. Это известный трюк, позволяющий спутать параметры между собой и мешающий возникновению мёртвых весов, по которым не текут градиенты. Подобное же использовалось в улучшенном конкретном автоэнкодере. Мои графики доли используемых кодов с всего лишь пары десятков процентов сразу взлетели почти до максимума.

Последние 10% были выбиты с помощью научного перебора расписания температуры. Оказалось, что результат очень чувствителен к нему - увеличение в несколько раз не в ту сторону забирало драгоценные проценты. Когда я сделал температуру e^-1 в начале обучения с переходом к e^0 в конце, то наконец увидел примерно 100% от изначального качества. Юзал 8/16 кодов с размером словаря 256. Чем меньше словарь, тем круче будет обобщающая способность у этих id-шников.

Применив результат к случайному набору постов, с первого же раза увидел, что похожие твиты имеют похожие id-шники, и в обратную сторону это тоже работало. Успех был достигнут. Внедрить, правда, их было не суждено, но это уже другая история.

@knowledge_accumulator

www.tg-me.com/ms/Knowledge Accumulator/com.knowledge_accumulator/290

1.8K viewsedited  Jun 10 at 08:55

RQ-VAE: практический гайд по выживанию

Несколько месяцев назад я делал обзор на статью по рекомендациям, базирующейся на так называемых Semantic IDs.

Напомню базовый смысл - мы хотим научиться сжимать большие эмбеддинги документов в список id-шников из небольшого словаря, которые позволяют сохранить большую часть информации о контенте документа. Расскажу про грабли, которые собрал, пока экспериментировал с этим у себя.

Первое и важнейшее - так как я человек ленивый, собирать отдельный пайплайн для обучения полноценного автоэнкодера я не захотел - с нашими миллиардами твитов в секунду любая операция над данными это больно. Созрел хитрый план.

Так как я уже работал над двухбашенной моделью, одна из которых относится к документу, вместо того, чтобы обучать codebook на восстановление документных эмбеддингов, я решил попробовать захерачить RQ-боттлнек прямо внутрь документной башни. То есть выход документного энкодера, прежде чем пойти дружить с юзерным вектором, проходил через эту квантизацию, а дальше шёл уже восстановленный вектор.

Можно спорить о том, насколько такая постановка портит итоговые id-шники. Мы пытаемся записать в них не полноценное представление, а только то, что помогает предсказывать рекомендательный таргет. Но у подхода есть мощный плюс - интерпретируемая процедура эвала качества сжатия.

Я строил 3 графика обучения двухбашенной модели. Два бейзлайна - нижний и верхний - без контентных фичей документа и обычный бейзлайн, и третий - это модель с RQ-боттлнеком. Если ошибка третьей модели ровно посередине между 2 бейзлайнами, то это значит, что мы как бы теряем 50% качества при использовании квантизации, т.е. не нужно никаких дополнительных анализов для неутешительного вывода. Моей задачей было максимально приблизиться к верхнему бейзлайну.

Как любой уважающий себя программист, начал я с воровства кода с гитхаба, нашёл вот такую репу на пару сотен звёзд и вытащил оттуда только код самого боттлнека. Напомню, главная сложность обучения дискретного боттлнека - он недифференцируем. В коде было 3 варианта решения этой проблемы - использование Straight Through Estimator. как в изначальной статье, господин Гумбель и ещё какой-то третий.

Первый и третий давали процентов 70% от изначального качества, а вот Гумбель давал процентов 30. Интуиция говорила, что Гумбель не может быть хуже, чем Straight Through Estimator. Так как же так? Ответ убил.

В коде с гитхаба после подсчёта матрицы расстояний между векторами и кодами зачем-то вызывался detach. Гумбель софтмакс - дефолтная опция этого, казалось бы, популярного репозитория, оказалась почти полностью сломана. После его исправления модель стала давать примерно 80% от качества бейзлайна. В репе эту ошибку исправили примерно в тот же самый момент, несколько месяцев до этого висела сломанная версия. Не доверяйте людям с гитхаба...

Переход от 80% к 90% произошёл благодаря опции sim_vq - трюка из этой статьи. Идея в том, что мы представляем матрицу кодов не как матрицу параметров, а как произведение 2 матриц параметров. Это известный трюк, позволяющий спутать параметры между собой и мешающий возникновению мёртвых весов, по которым не текут градиенты. Подобное же использовалось в улучшенном конкретном автоэнкодере. Мои графики доли используемых кодов с всего лишь пары десятков процентов сразу взлетели почти до максимума.

Последние 10% были выбиты с помощью научного перебора расписания температуры. Оказалось, что результат очень чувствителен к нему - увеличение в несколько раз не в ту сторону забирало драгоценные проценты. Когда я сделал температуру e^-1 в начале обучения с переходом к e^0 в конце, то наконец увидел примерно 100% от изначального качества. Юзал 8/16 кодов с размером словаря 256. Чем меньше словарь, тем круче будет обобщающая способность у этих id-шников.

Применив результат к случайному набору постов, с первого же раза увидел, что похожие твиты имеют похожие id-шники, и в обратную сторону это тоже работало. Успех был достигнут. Внедрить, правда, их было не суждено, но это уже другая история.

@knowledge_accumulator

BY Knowledge Accumulator